Skip to main content

Hexo博客搭建那些事儿,考核系列相关文章-1

· 9 min read
yeshan333

博客考核任务发布之后有同学问了各种各样的问题,(趁着大家基本考完试了)发篇博文略微总结下。

说说我们的感受

我们发现有不少同学的问问题方式还是有一定的问题的。部分同学提供的信息不够精确,比如:

问题信息不清

这个同学一开始问了个:hexo 源的问题怎么解决? 其实第一眼看到这条信息,我们是无法真正确定你遇到的问题的。而且这个用词也有一定的问题,「hexo源?」,这位同学想说的是 npm 源吧。而且,这位同学一开始并没有提供截图说明他的问题,这是一个很不好的习惯『一般情况下,软件/程序出错都会有错误信息提示,这部分内容可以提供给我们』。问问题时,说明遇到的问题和给出提示信息图是很重要的,可以帮助被提问方快速的定位问题。

不过这位同学能通过搜索先去解决问题还是值得肯定的,只是搜索的姿势好像不太对,把握不住引起问题“要害”->no such a file or directory xxx package.json。「关注提示信息,这里不得不吐槽的是居然有中文路径,建议尽量不要使用中文路径」

no such a file or directory xxx package.json

到此,不得不提社区上比较火的一个话题,如下图「当然,我们也不强求所有同学都能做到,扎实成长,慢慢打磨即可」:

提问的智慧

从问题中了解到的知识点

正如我们之前那个线上小讲堂所说:你们问问题,不仅在帮你们,也在帮助我们。你们问问题的同时也在帮助我们更加理解我们之前学的知识「经过时间的洗刷,部分知识并非如我们想象的那般熟悉」。

OK,接下来谈谈从你们的问题中,我们会有一些怎么样的思考,你们/我们又学到了什么?

  • 1、从no such a file or directory xxx package.json引申出来的问题。

之前遇到这个问题的同学可能只想着把博客搭建起来就好了,可能并没有思考这个文件package.json到底是干嘛的,且网上的大部分 Hexo 博客搭建教程并没有提及这个文件存在的意义。

那么这个文件按到底是干嘛的?其实我们的整个 Hexo 博客,相当于一个轻量级的项目(Node.js Project)。既然是项目就会有依赖,一个有一定规模的项目,肯定会引用各种的第三方 plugins(modules、packages、framework等)。package.json文件,定义了这个项目所需要的各种模块,以及项目的配置信息(比如名称、版本、许可证等元数据)。具体可看这里->🔗

到这里,我们还会引申出来一个思考,我们hexo init后生成的文件/目录的用途是什么?其实这些东西 Hexo 官网有基本的陈述->Docs。不得不提的是,我们既然用别人的产品,那么我们遇到问题的时候肯定可以借助产品的社区解决,我们应当多关注一下我们使用的技术产品的技术社区 -> Hexo Framework。很多我们使用过程中遇到的问题基本都能在 Docs/troubleshootinggithub issues中找到解决方案。

值得一提:现在我们可以通过 npx 运行 node_modules 中的 binary/executabl file 了,不用在全局安装某些模块了(npm install -g),具体可了解:npx 使用教程

  • 2、从 command not found 引发出来的思考-环境变量(environment variables)问题 。

不得不说,环境变量的问题是值得引起重视的。在以后成长的过程中,我们肯定会因为Java、Maven、Python、GOPATH或生产线上部署项目等各种乱七八糟的东西的环境变量使用姿势不对遇到各种小问题。

先通过实际例子理解一波环境变量,就博客搭建这件事而言,相信会有小部分的同学在博客搭建过程中遇到或npmgit等命令使用不了的情况。这些情况一般是因为没有将与这些命令相关的可执行文件(executable file、binary)加入环境变量中所致。可以拿以下这么一个 C 程序做下比喻:

//helloworld.c
#include<stdio.h>

int main() {
printf("Hello World");
return 0;
}

我们先编译一下这个文件。

gcc -o hello .\helloworld.c

然后执行一下可执行文件,可以看到,我们可以在当前工作目录(工作空间,workspace)执行这个可执行文件是可以的,但是换到另一个 workspace 就不行了。有同学会说,我们使用绝对路径不就好咯。懂得都懂,程序员比较懒。以后想要多次复用程序,总不能每次都打那么长一串吧。这时候环境变量就派上用场了(环境变量还有很多用途)。

这时候我们可以通过 set 将 hello.exe 所在目录加到环境变量中(Linux 可使用 export)。

workspace

set Path=%PAth%;C:\Users\yeshan\Desktop\goxxx

set 设置环境变量

这下,可以看到,我们可以不必在 hello.exe 所在的 workspace 才能执行它了。「有那么点 C 语言全局变量和函数局部变量的味道了,但又不完全是」。

这就完了吗?并没有结束。看下下面这波操作。

进程间上下文不一样

可以明显看到,通过 set(export)的方式设置的环境变量并不是永久的,还需要做下其它花哨设置才可以,这里不做介绍。我们仅以此做个引申,我们可以继续思考什么?我们可以思考一下这是为什么?

这是因为两个进程(terminal process)是隔离的,上面那种情况,另一个进程中资源的变化影响不了另一个进程(左边的将 hello.exe 文件的工作目录加入 path 对右边的无效)。那么?terminal 进程的 path 信息从何而来?它从父进程而来,subprocess(子进程)的资源由父进程继承而来「system call -> fork()」。到这里,就应该了解一波操作系统相关的知识了,感兴趣的同学可以看下《现代操作系统》这本书。顺便了解下进/线程模型、进程和线程的区别吧。2333~卢瑟✨✔👍。

进、线程资源持有区别

tip

这里仅做一个引导,说明我们如何从一个简单问题开始思考,抽丝剥茧,深入了解底层原理。

引用